Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/974

Text File | 1994-08-27 | 6KB | 140 lines

Subject: GEM-List
Subject:  Re: Gem List (Please Post!) (fwd)
Subject:  digest
Date: Sun, 24 Jul 94 22:51 EST
From: "Daniel J. Hollis" <[e-mail]>
To: ems <[e-mail]>
Subject: GEM-List
Message-Id: <54940725035145/[e-mail]>
Precedence: bulk

Subject:  Re: Gem List (Please Post!) (fwd)

Warwick:
--------
>>> Are you talking about WinLIB PRO?  Ken once sent me a demo version.  It
>>> died a horrible death under my NOVA VDI.
>>What version of NOVA VDI were you using? Other people have used it on
>>NOVA cards (and various other video cards) with no problems. On the other
>>hand, old versions of the NOVA VDI drivers have numerous bugs.
>It was the current NOVAplus VDI available at the time.  By all means,
>send it again and I'll have another try.

Yeah -- but that was over a year or so ago, right? Besides the fact that
WinLIB PRO mainly uses existing GEM routines and AES -- it hardly touches
the VDI. It worked on the Falcon030 (numerous resolutions, including color,
with and without NVDI), a TT030 (both Mono 19" and color), a MegaST with
a Gadgets 030 board.

Your setup was the only machine that WinLIB PRO *didn't* work on. And
since other users also had NOVA cards, I wonder why your machine was the
only one with problems? :-)

I recall you were posting on c.s.a.st a while back that such and such
programs crashed on your machine/NOVA combination, and we discovered that
nobody else seemed to have problems. Maybe you just have a flakey machine?
It could have also been the copy of the archive... Sometimes ZIP likes to
corrupt itself for no apparent reason. @_@

--Dan Hollis
----------
Subject:  digest

>>> Click on a window border, or the window move bar (in the latter case
>>> remembering that a click and a drag are different, of course)
>> My concern is that you are now changing "previous" behavior.
> Clicking on the title bar has always topped the window.  Under X11, this is
> also the case.  What we are changing is that now clicks on things inside the
> work area now actually work, rather than just causing the window to top.
> Yes, this is a change of behaviour, but it is a change to a MORE logical
> operation, so it is very easy for users to accept, especially since it
> makes their life easier.

Ahhh, some people are content to live with obsolete "standards" set by
Atari. While some people actually have vision for the future :-) Seems that
Geneva is a bit short sighted. :-) :-)

>>========================================================================
>>Really? What about objc_edit() which can't clip to a rectangle list?
>>========================================================================
>>Don't allow user to edit field unless entire editable field is completely
>>visible (gotta walk lots of rectangles, very often).
>Another approach is to do the edit field as a form - ie. when editing
>it, use form_do just drawing the edit field.  I haven't tried this yet,
>but it seems feasible.

Yet another approach is to write your own objc_edit() routine. Not only
does it give you more flexibility, but you also get rid of bugs like
TOS 1.0's problem with underlines in some editable fields.

It's actually not that difficult! It took only a day to write one. The
optimizations itself took a couple of days, but it takes time to get a
routine perfect. :-)

> >>(GEM treats focus==top, in the hope that it is far
> >> more efficient to update a top window, but in reality, this is not the
> >> case
> >This is news to me; if you are updating the top window, you can use
> >raster copies (because your work area is not obscured by anything).  This
> >makes it a trivial task.  If you are not the top window, though, you have
> >to walk the rectangle-list and redraw all kinds of little things.
> Yes, it was suprising to me too.  But it turns out you can still use raster
> copies on partially obscured windows.  And sometimes, the fact that some of
> the area to raster-copy is obscured means the raster-copy goes faster, and
> hence is faster.  Net gain for top windows is very little.

Actually this should have been obvious to most people. As long as GEM is
giving you rectangle lists, you should be able to whatever you want to
with those rectangles :-)

> >3 - All graphics in windows (including window 0 with proper wind_set)
> IMO, applications should not use the desktop for its own.  At the very
> least, it should be configurable (Interface is a good example of this).

Or, support 'desktop in a window' ala Interface. :-)
Some programs have a *reason* to use the desktop, i.e. what about programs
that replace the desktop with a picture? Or screen savers? :-) (Actually,
there are several 'legitimate' ways to do a screen saver without using window
0, but I was just using it as an example. :-)

> > 9 - No form_do() or other locking calls.
> Alerts lock, and they *SHOULD* freeze the display until the user
> responds (that's why they're called alerts!)

Ah yes -- but alerts should not be used for anything except catastrophic
errors, not stupid things like "Save file -- Are you sure? [Yes][No]"

> It is difficult for the author of the application to know when this is the
> case, so dialogs-in-windows is much easier.

Especially when a library will do it for you with almost *no* effort.

> Ken/Goemon/Gehenom/Dan Hollis:
> >XAES (the reworked version of WinLIB PRO) is 238,592 bytes.
> After all that complaning about size!  GEM++ 1.99 is only 173,884 bytes.
> (example.prg, which exercises most of the library compiles to 135010 bytes).
> And I'll be the first to admit that GEM++ isn't intended for developing
> small GEM applications.

"Gehenom"? That's a new one. :-)

Re: 173,884 bytes... well, last time I checked Gem++ had a library of
roughly 500k, and the demo programs were 200k or so (and they bombed more
often than not.) AFAIK the newest version of Gem++ available for FTP is from
early 1993.

As long as my library does what I want it to do, size is not a concern of
mine. :-P

> To the scheme of top-AND-select:  Why?  Just select it.  The only
> reason I can imagine is that topping first means you never have to walk
> the rectangle list when selecting objects.  But your code must already
> implement that anyway (for redraws), so there's no gain.

I agree. The only argument against using most of these _SIMPLE_ techniques
is pure laziness. Especially when the techniques have been *spelled out* in
example code for everyone!

--Dan Hollis